feat: warn on non-default checkout during pull_request_target#2430
Open
KengoTODA wants to merge 1 commit into
Open
feat: warn on non-default checkout during pull_request_target#2430KengoTODA wants to merge 1 commit into
KengoTODA wants to merge 1 commit into
Conversation
Signed-off-by: Kengo TODA <skypencil@gmail.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a runtime warning to actions/checkout when a pull_request_target workflow explicitly checks out a non-default ref from the workflow repository, with an explicit opt-out input to suppress the warning.
Changes:
- Emit a warning in
getInputs()whenpull_request_target+ workflow repo + explicitref+ non-default ref (unless suppressed). - Add
dangerously-checkout-non-default-branchinput to suppress the warning. - Document the new input and add unit tests covering warning/no-warning scenarios.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/input-helper.ts | Implements the warning logic and adds helper to detect default-branch/current-SHA refs. |
| test/input-helper.test.ts | Adds tests validating warning behavior and the suppression input. |
| action.yml | Declares the new dangerously-checkout-non-default-branch input (default: false). |
| README.md | Documents the new input in the usage section. |
| dist/index.js | Updates the compiled distribution output to include the new behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello team, thanks for your continued contributions to the OSS community! 👋
Summary
This PR adds a warning when
actions/checkoutis used from apull_request_targetworkflow to explicitly check out a non-default branch (or ref) from the workflow repository.The intent is not to block every such workflow. There may be legitimate cases where a workflow intentionally treats pull request contents as passive data. However, in practice, checking out a pull request-controlled ref in
pull_request_targetis easy to misunderstand and can put untrusted code into a privileged workflow context.This pattern was part of the issue described in the TanStack npm supply-chain compromise postmortem:
https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
GitHub Security Lab has also documented this class of problem as “pwn requests”:
https://securitylab.github.com/resources/github-actions-preventing-pwn-requests
Proposed behavior
When all of the following are true, the action emits a warning:
pull_request_targetwith.refis explicitly setThe warning can be suppressed with:
The dangerously prefix is intentional. The goal is to make the risky case explicit in workflow code, while still allowing maintainers who understand the tradeoff to opt out of the warning.
Why this seems worth considering
This is a relatively small change, but I think it could help the broader Actions community avoid a recurring footgun. The current behavior is technically flexible, but the security implications of pull_request_target are subtle enough that a warning at the point of use seems valuable.
I am opening this PR as a starting point for discussion. I would be happy to adjust the wording, the option name, or the exact detection logic based on maintainer feedback.
Thank you!